re:Invent 2022の『What’s new with Amazon EMR』からEMRに入門した #reinvent #ANT302

非常に詳しくAmazon EMRの機能について紹介されていることに加えて、分散処理システムのパフォーマンス改善例としてもとても学びが多いセッションでした。

AWS re:Invent 2022

#AWS

#Amazon EMR

nayu.t.s

2023.07.23

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

データアナリティクス事業本部の鈴木です。

ちょっと時間が経ちましたが、AWS re:Invent 2022の、セッション番号ANT302の『What’s new with Amazon EMR』を聴講したのでレポートです。re:Invent 2022時点での、Amazon EMRの機能紹介セッションです。

最近は、例えば以下の記事のように、Amazon Athena for Apache Sparkについていろいろ調べてまとめています。

従来のサービスで大規模なデータに対する、インタラクティブな分析の選択肢として比較に挙げられるのはAmazon EMRです。

このセッションを通じて、改めてAmazon EMRの機能を学んだのでご紹介します。

セッション内容

セッションについて

Session type

Breakout Session

動画

スライドPDF

AWS Events Contentより確認しました。

https://d1.awsstatic.com/events/Summits/reinvent2022/ANT302_Whats-new-with-Amazon-EMR.pdf

セッション概要

Amazon EMRは、オープンソースフレームワークを使用して構築されたビッグデータアプリケーションの実行とスケーリングを実現しやすくします。ETLやペタバイトスケールでの低レイテンシSQLの高速化を支援します。Amazon EMR Serverless、Amazon EMR Studioなど、最新のAmazon EMRを利用した開発についても学びます。

私のまとめ

簡単にですが、セッションにてポイントと感じた点と、関連して調べた内容についてご紹介します。かなりみっちりAmazon EMRの紹介をしているセッションなので、かいつまんでいるところも多いですが、ご興味がありましたらぜひセッションをご覧ください。

コスト最適化について

Amazon EMRを使うことで、オンプレミスでHadoopクラスタを構築するよりも遥かに大きいコストメリットを受けることができる。

オンプレミスとEMRの比較

Amazon EMRの中では3種のコスト最適化オプションがある。
- クラスターが必要なときに正確に起動しワークロードが終わると終了するTransient clustersの機能は、永続的なクラスタの平均利用率が40％しかないことから、大きなコスト削減に繋がる。
- スポットインスタンスを利用すると、オンデマンドインスタンスに比べて最大90％の割引を受けることができる。EMRはスポットインスタンス停止前の警告を受けて、より健全なインスタンスにジョブを割り当てる仕組みのため、中断されるワークロードは5%未満に抑えられる。
- インスタンスフリートを使えば、EC2インスタンスの種類に多様性を持たせ、マルチAZ構成を実現することができる。

コスト最適化

上記のコスト最適化オプション以外にも、様々なコスト最適化の方法がある。
- インスタンス種別はGraviton2に移行しているユーザーが多い。AWSのベンチマークによれば、Graviton2はM5インスタンスタイプに対して12～16％の性能向上を実現した。対応するx86バージョンよりも20％低い価格となっており、正味で30％の価格改善となる。ただし、ハードウェアのアーキテクチャがARM64であるため、特定のライブラリは再コンパイルが必要になる可能性があることは考慮が必要になる。
- マネージドスケーリングにより、よりリアルタイムにEMRクラスタをスケールすることができ、最大20～60％のコスト改善を達成できる。
- インスタンスを一時的に起動・終了するようなケースでは、起動時間もとても重要な要素となる。AWSはプライベートサブネットのEC2クラスタ上でEMRの起動時間を最大30％短縮した。加えて、マスターノード・コアグループ・タスクノードを並列に起動するようにも対応した。
- Managed Scalingでは、Sparkのシャッフルデータを効率よく利用できるようなスケーリング方式を実現し、処理のパフォーマンス改善をした。
- GP3ボリュームを利用することでEBSの改善のメリットを受けることも可能となった。

EMRのエンハンス内容

Transient clustersは、開発者ガイドの『Configuring a cluster to continue or terminate after step execution』にて紹介されていました。

Managed ScalingのSparkシャッフルデータ対応については、以下のアナウンスが該当すると思われます。

Amazon EMR on Amazon EKSについて

EMR on EC2とは異なり、数秒でジョブを開始できる。マルチAZクラスタの構成もできることに加え、複数のワークロードが共存することができる。

Amazon EMR on Amazon EKS

Amazon EMR on Amazon EKSの新しい機能としては4点ある。
- データエンジニアがジョブをクラスタに投入する際に必要な引数やパラメータを最小限に抑えることができるジョブテンプレート
- パイプライン全体をSQLスクリプトとして指定することができるSpark SQL Runner
- DynamoDBコネクタ
- ジョブのエラーメッセージの強化

Amazon EMR on Amazon EKSの新しい機能

Amazon EMR on Amazon EKSについては、『Run Apache Spark on Kubernetes with Amazon EMR on Amazon EKS』の資料がありましたので、URLをご紹介します。

https://d1.awsstatic.com/events/Summits/reinvent2022/ANT330-R_Run-Apache-Spark-on-Kubernetes-with-Amazon-EMR-on-Amazon-EKS.pdf

パフォーマンス最適化ランタイムについて

EMRはSpark、Presto、Trino、Hiveは100％オープンソースと互換性があるが、これに加えてランタイムを最適化している。
EMR6.5とEMR6.9を比較すると、同一ベンチマークで1.3倍速くなっているため、EMRを最新バージョンに保つのは意味がある。
OSSのバージョンと比較すると以下のような差がある。
- EMR 6.9.0（最適化したSpark） vs. OSS Spark： EMR6.9.0が3.9倍速い
- EMR6.9.0（最適化したSpark） vs. EMR6.5.0（最適化したSpark）: EMR6.9.0が1.3倍速い
- EMR 6.9.0（最適化したTrino） vs. OSS Trino： EMR6.9.0が4.2倍速い
- EMR 6.9.0（最適化したHive zero-rename機能版） vs. OSS Hive： EMR6.9.0が15倍速い

測定条件の詳細については、資料スライドのP.17 - 20を参照してください。

zero-rename機能については以下のAWS Big Data Blog記事にも記載があります。

エンジンの改良について

PrestoおよびTrinoの改良

Spot loss handling機能の追加・Lake Formationとの連携により、きめ細かなアクセスコントロールへの対応など、5点の追加をした。
- 特に、1点目のSpot loss handlingについては、Presto、Trino向けにはスポット的な中断に弱いため、スポット障害処理のロジックを追加した。具体的にはスポットインスタンス終了警告を見て2分以内に終了するなら続行、しないなら別のインスタンスで再投入するようにした。

Presto/Trinoの改良

この機能については、リリースガイドのHandling Spot Instance loss in Presto - Amazon EMRにも説明がありました。

Hiveの改良

zero-rename機能、MSCKの改良（S3のListObjectsのAPI呼び出し回数を減らした）など6点の追加をした。

Hiveの改良

MSCKの改良については、Athenaで実行した際にS3のListObjectsのAPI呼び出し回数が非常に多くなってしまう課題がシステム設計によっては発生します。EMRではこの点に改良が入っているのは非常に素晴らしいですね。

Transactionalデータレイクに向けての機能について

EMRでのユースケース

GDPRのようなコンプライアンスプログラムを遵守するような場合に、データの削除やそれ以外のトランザクション処理を実現するパイプラインが必要な例として、ストリーミング取り込みパイプラインおよびCDC取り込みパイプラインが挙げられる。
特にストリーミングの場合は、作成されるファイルが小さくなってしまうため、一定の周期で大きなファイルにコンパクト化する必要がある。

ストリーミング取り込みパイプライン

CDC取り込みパイプライン

Transactionalデータレイクを実現するためにサポートするフレームワーク

セッション発表時で、以下のフレームワークをサポートしている。
- Apache Hudi 0.12
- Apache Iceverg 0.14.1
- OSS Delta Lake 2.1.0

Transactionalデータレイクの機能１

Transactionalデータレイクの機能２

EMRサーバーレスについて

EMRサーバーレスは、EMRサーバーレスアプリケーションを立ち上げる際にEMRのバージョンとエンジンを選ぶだけでよい非常にシンプルなもの。
- ジョブおよびステージがワーカーを必要とするときに自動的にスケールする。需要が落ち着くとワーカーが削除される。この自動的できめ細かなスケーリングによって、コストを最適化することができる
Apache Airflowとネイティブに統合している。もちろん既存のGlueカタログをメタストアとして活用することができる。

EMRサーバーレスの背後にある主な構成は以下スライド記載の3つの要素がある。

EMR Serverlessの3機能

ワーカーについては、適切なサイズに調整することができる。またジョブを高速に起動させたいユースケースで、Pre-initialized workersが利用できる。
Amazon EMR ServerlessではマルチAZ構成にすることができる。使用するコンピューティングリソースの上限を設定できる。
ユーザーはAmazon EMRアプリケーションを共有することができ、ジョブごとの実行ロールにより、同じアプリケーションでも異なるリソースにアクセスをする制御が実現できる。

ジョブごとの権限制御

SparkのグラフィカルUIやCloudWatchにより、クラスタの状態をリアルタイムにモニタすることができる。
EMR ServerlessもGraviton2を選択することができ、コストおよびパフォーマンスにメリットがある。

EMR ServerlessのGraviton2利用

EMR Studioについて

フルマネージドな統合開発環境 (IDE)。JupyterノートブックやSpark UIなどを使い、デバッグを簡素化できるほか、パラメータ化したノートブックをApache AirflowのDAGの一部に組み込むなどもできる。

EMR Studio

EMR Studio２

ここで紹介されている機能については、製品ページでも動画とあわせて確認できるため、ぜひご覧ください。

セキュリティについて

Job runtime rolesにより共有のクラスタであっても、EMRのジョブごとにアクセスできるリソースを設定することができる。
LakeFormationと連携することで、きめ細かなアクセスコントロールを実現できるようにもなった。例えば以下のように　SageMakerからのアクセス時にEMRとLakeFormationを通して、S3バケットにあるデータへのアクセス制御を実現できる。

SageMakerとEMRによるFGAC

感想

『What’s new with Amazon EMR』のセッションの内容は、単にAmazon EMRの機能紹介にとどまらず、普遍的なデータ分析基盤の課題とそのアプローチ例の紹介でした。特にAmazon EMRにおける分散処理システムのパフェーマンス改善の工夫に関する説明がふんだんに盛り込まれており、非常に面白く勉強になるセッションでした。

セッションを見るまでは、EMRはオンプレミスのHadoopのリフトアンドシフトが主な用途なのかなと考えていましたが、以下のような特徴があるように理解しました。